gtk3-demo: Make blendmodes example non-resizable

It doesn't need to.

Fix parsing of some css properties

Our property parser stops at the first match when looking for
enums, so we need to order our values so that we don't end up
with prefixes of longer names being found first.

I noticed this when the parser tried to interpret
background-blend-mode: color-burn; as "color, with junk at the end".

It also affects animation-direction, which is also fixed here.

css parser: Improve an error message

Say what property we are dealing with when we complain about the
value.

demo: add a demo for blend modes

After introducing the CSS blend mode enum values and including
the background-blend-mode CSS property, it is very important to
actually provide an example of the new feature.

This patch adds a new demo to gtk3-demo which shows how the
background-blend-mode CSS property works.

https://bugzilla.gnome.org/show_bug.cgi?id=768305

css: add documentation for background-blend-mode

After introducing the new CSS property, it is natural to
add some documentation explaining the behavior of it and
our support coverage.

https://bugzilla.gnome.org/show_bug.cgi?id=768305

css: add background-blend-mode support

CSS supports blend modes, in which a series of layers are
merged together according to the given operation or set of
operations.

Support for blend modes landed on Cairo, which exposes all
the commons and also the exquisites blend modes available.
Adding support for blend modes, then, is just a matter of
using the available Cairo operations.

This patch adds the background-blend-mode CSS enum property,
and adapts the background rendering code to blend the backgrounds
using the available blend modes when they're set.

https://bugzilla.gnome.org/show_bug.cgi?id=768305

Simplify the xfce session manager support

We don't have to check name owners twice; reuse the information
we already have.

GtkApplication: Add support for the Xfce session manager

Xfce4-session-manager added support for managing dbus based clients.
This patch adds support for checking if Xfce session manager is
around after trying the gnome one.
https://bugzilla.gnome.org/show_bug.cgi?id=693203

Fix example Makefiles

Put OBJS before LIBS on the commandline to make things
work better.

https://bugzilla.gnome.org/show_bug.cgi?id=768142

print dialog: Apply initial capabilities

I was struggling to understand why calling
gtk_print_unix_dialog_set_manual_capabilities (...,0)
was not having the expected effect of hiding the preview
button. The initial capabilities were not applied at all.

wayland: Separate selection buffers and other per-selection atom data

This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
  GDK_SELECTION_NOTIFY events generated will have unexpected info if the
  buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
  target.

This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.

https://bugzilla.gnome.org/show_bug.cgi?id=768177

wayland: Implement gdk_utf8_to_string_target

The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.

https://bugzilla.gnome.org/show_bug.cgi?id=768082

gtk/gtkstylecascade.c: Fix formatting

My previous patch on this file did not take into the account of the
formatting, sorry!

headerbar: don't throw a warning if title widget is hidden

commit 0015ebc4a8f269f6888fcacef3e83e3167241d67 reworked
some of the titlebar size allocation code.  Those changes
inadvertently introduced a warning when the application sets
the headerbar title widget to be hidden.

This commit fixes that warning.

https://bugzilla.gnome.org/show_bug.cgi?id=768184

configure: fix "AC_RUN_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS"

gdk: actually fix the previous commit

We do not want it on windows

gdk: do not provide display command line argument on windows

There is no need to specify a display on windows.

GtkWindow: Check for GtkWidget-window-dragging in multipress gesture

This partly reverts 9f5b9c0e075e2426d6627f867473e911fca0c7ae, which
removed the check for GtkWidget-window-dragging in the multipress
gesture. This check is still needed for widgets which have this style
property set (e.g. menubars and toolbars) can maximize the window on
double click -- but those widgets which have it set to FALSE shouldn't
maximize the window.

gtkfilesystem: Improve heuristics to detect remote filesystem

Use G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE to detect remote filesystems
instead of hardcoded list of filesystem types.

Bump required GLib version accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=767965

GtkWindow: Fix dragging on non-titlebar widgets

widget: Don't unnecessarily export function

_gtk_widget_get_translation_to_window is only used in gtkwidget.c

gtk/gtkstylecascade.c: Declare variables at beginning of block

Fix build of commit f23e99b

Commit f23e99b made use of snprintf(), which is not universally available.
Fix this by using g_snprintf().

Updated Indonesian translation

Updated Indonesian translation
(cherry picked from commit 23673851b7e51c67a02f8171161b89111fec249b)

Updated Hebrew translation

Adwaita: color the selection of entries with error...

...or warning style class applied.
This particular style bit wasn't converted to the saner 3.20 way
so `entry:selected` used in place of `entry selection`.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768025

Adwaita: restrict infobar styling to, well, infobars

we used to style infobars by using the .info, .question, .warning
and .error selectors directly, which used to be ok when we had just
styleclasses all over the place, now it needs to be more specific
or it interferes with everything with those styleclasses applied
like entries.

Updated Indonesian translation

Updated Indonesian translation
(cherry picked from commit 3abb9ffa917611e81cc4cb50b7ddd38879a49b8f)

headerbar: support expand property for children

The header bar currently ignores the expand property on its
children. This commit changes the code to honor that property.

It divvies up any free space and distributes it equally to packed
children (with any left over space given out a pixel at a time
on a first come, first serve basis).

This commit also adds support for the title widget to be made
expandable.

It accomplishes this by using up the padding the title widget
is centered with.

https://bugzilla.gnome.org/show_bug.cgi?id=724332

headerbar: compute nominal size of sides up front

In order to support the expand property on children, we're
going to need to look at the size of the packed children
on each side of the title widget, up front, before allocating
them (to compute how much extra allocation each expanded child
gets).

This commit lays the groundwork for that analysis by splitting
the size calculation of each side of the header bar outside
of the loop that allocates each child of the header bar.

https://bugzilla.gnome.org/show_bug.cgi?id=724332

headerbar: simplify some size allocation code

With a headerbar, the widget in the center may be a label, constructed
internally, or a custom widget, constructed externally.  The size
allocation code needs to handle either case the same way for the most
part.  There's more than one place in the code that checks which of
the two widgets to use and does some operation on the selected one.

This commit simplifies the code by checking up front which one is the
center (title) widget and storing that in a temporary variable,
This allows reducing duplicated logic later on in the function.

https://bugzilla.gnome.org/show_bug.cgi?id=724332

headerbar: simplify calculation in size allocation code

There's some extraneous MIN() calls that have predetermined answers.

This commit drops them and then simplifies a few redudant checks into
one MIN call.

https://bugzilla.gnome.org/show_bug.cgi?id=724332

Fix an array overrun

When I introduced the new input source enum value for
track points, I forgot that there is a fixed-size array
with names for those in the inspector.

headerbar: don't use GTK_PACK_* as indices into array

The size allocation code maintains an array of two elements,
to track the allocation of children packed into the two sides
of a header bar. Sometimes this array is indexed with 0 and 1,
and sometimes its indexed with GTK_PACK_START and GTK_PACK_END.
The latter happen to have the values 0 and 1, respectively, but
that's not really obvious.

For clarity, this commit changes the code to index those arrays
consistently, sticking to 0 and 1 across the board.

headerbar: don't allocate both label and custom title

It's only possible to have a label or a custom title, not both.
The size allocate code confusingly treats them as independent.

That is confusing, because, as the code is written, it makes it
look like the space for the custom title isn't getting accounted
for.

This commit else-ifies some parts of the size allocate code for
clarity.

Updated Portuguese translation

gtk: Keep Firefox working in the DrawingContext world

Firefox does a bunch of interesting things with GTK.

If the top-level GtkWindow does not have a "csd" style class associated,
Firefox will happily draw the contents of the container used to render
HTML and XUL directly on the top level's GdkWindow; on the other hand,
if a "csd" style class is found, the MozContainer will create a new
child window, and draw on it.

Then, Firefox will proceed to disable double buffering on both the
top-level window and the MozContainer (unless they are backed by the
same GdkWindow, in which case only the top-level will be
single-buffered) *and* it will add a GDK_EXPOSURE_MASK flag to the
MozContainer events for good measure (even if this is only needed for
GTK+ 2.x).

After landing the GdkDrawingContext API in GdkWindow, GTK enabled
automatic double buffering on all top-level windows backed by a native
surface, ad most users of single buffering rely on child widgets instead
of top-levels, and we'd still like to have the same double buffering
behaviour for all top-levels on all backends. Obviously, with Firefox
disabling double buffering on the top-level window, the change broke
their drawing mechanism.

Ideally, Firefox could be fixed to not disable double buffering on the
top-level window when MozContainer has a separate GdkWindow — i.e. the
CSD case — but since we did introduce a slight change of behaviour in
fringe users of the GTK+ API, let's keep backwards compatibility with
the old code for a little while longer, and create an intermediate Cairo
context unbound from the GdkDrawingContext, like we used to do until
GTK+ 3.20.

Visual Studio builds: Make .pc generation more flexible

Allow the use of ${exec_prefix} for libdir and includedir when passing
them in as arguments to the script.

GtkColorEditor: Keep ref on pre-popup focus widget

And ensure it's still visible before returning the keyboard focus to it.
Because of the extra ref, add a dispose handler that will ensure the
ref is lost (by popping down), although this should be already ensured
through other paths (eg. when the popup widget loses visibility).

This fixes a possible crash in dispose paths, where we might be restoring
focus on an already destroyed widget, and at a time where, if the toplevel
is being itself disposed, no new focus should be set.

https://bugzilla.gnome.org/show_bug.cgi?id=767849

demos: Simplify popovers demo

Don't do much unconventional stuff here. This is a demo, not a test.

https://bugzilla.gnome.org/show_bug.cgi?id=767851

GtkPopover: Honor widget margins when calculating tail position

If there are widget margins set, the whole popover will be displaced.
However the calculation of the tail position doesn't have this into
account, ending up with the tail being detached from the popover if
the margin grew too big.

We should not render the arrows invariably next to the GdkWindow edge,
but optionally displaced inside it depending on the widget margins.
Fixes the gtk3-demo "Popovers" demo case, whose GtkEntry popovers set
widget margins for some reason.

https://bugzilla.gnome.org/show_bug.cgi?id=767851

listbox: short-circuit if no sort function is set

do_sort will crash if sort_func is not defined. Instead of adding a check
there in the hot path, just check for sort_func before invalidating the
sort of the underlying GSequence.

3.21.3

Skip GdkDrawingContext in some tests

GdkDrawingContext is not freely constructible, so we need
to skip it in the notify and finalize tests.

wayland: do not set PRIMARY selection if focus is lost

If keyboard focus is (already) lost, do not advertise PRIMARY selection.

https://bugzilla.gnome.org/show_bug.cgi?id=767848

Updates

gtk3-demo: Make the filter model example more interesting

Allow editing values in the first treeview, to see the derived
models update in real time.

shortcuts: Try harder to disambiguate search items

I noticed that some of the gestures did not show up in the
search results in the builder example in gtk3-demo, because
they share the same title and don't have an accelerator to
disambiguate. Include the shortcut type to handle this case.

gtk-demo: Use max-content-height in the popover example

This is what the property was invented for.

gtk3-demo: Fix the modelbutton example

The color menu buttons didn't have the necessary target property
to be successfully activated.

gtk-demo: Fix up some warnings

The search entry example was a bit sloppy in cleaning up its
sources, causing warnings.

Add a release note for scrolled windows

Mention the changed sizing behavior and how to address it.

widget factory: Adapt to new scrolled window behavior

Set a max-content-width on some of the scrolled windows to
keep things looking mostly the same, now that GtkScrolledWindow
passes along the natural size of its child.

treeview: Ensure the treeview has the implicit grab before grabbing focus

The cellrenderer signals might be taking the grab somewhere else, at which
point it's dubious we should attempt to take the keyboard focus into the
treeview.

This concretely breaks popovers triggered from cellrenderer signals on
button press, because the treeview will attempt to grab focus
inconditionally then.

https://bugzilla.gnome.org/show_bug.cgi?id=767468

GtkActionHelper: Change a message to a warning

It's almost certainly a programmer error if an action isn't
activatable because its target and parameter type don't match.
This commit changes the existing g_message to a g_warning.

https://bugzilla.gnome.org/show_bug.cgi?id=767705

style cascade: Allow cascades with more ancestors

Previously a style cascade's parent could not have a parent itself. That
represented the two levels at which you could add a style provider: at
the screen level, with gtk_style_context_add_provider_for_screen(), and
at the style context level, with gtk_style_context_add_provider().

This commit changes no functionality, but this change will be necessary
for adding style providers in the future that apply to a subtree of the
widget tree. It relaxes the requirement that a style cascade's parent
must not have a parent, since in the future a style context may be
affected by any number of parent widgets' style contexts.

https://bugzilla.gnome.org/show_bug.cgi?id=751409

shortcuts window: Fix handling of significant xml chars

We are using markup in the labels, so we need to escape things
like < and >.

https://bugzilla.gnome.org/show_bug.cgi?id=767795

Updated Brazilian Portuguese translation

Updated Brazilian Portuguese translation

configure: fix detecting CUPS 2.x

https://bugzilla.gnome.org/show_bug.cgi?id=767766

wayland: fall back to shm_open if memfd unavailable

Debian stable currently ships with a 3.16 kernel, so
it doesn't have memfd available.

This commit adds shm_open fall back code for that case
(for now).

https://bugzilla.gnome.org/show_bug.cgi?id=766341

wayland: fix error handling for memfd_create

We currently use syscall() directly to invoke memfd_create,
since the function isn't available in libc headers yet.

The code, though, mishandles how errors are passed from syscall().
It assumes syscall returns the error code directly (but negative),
when in fact, syscall() uses errno.

Also, the code fails to retry on EINTR.

This commit moves the handling of memfd create to a helper function,
and changes the code to use errno and handle EINTR.

https://bugzilla.gnome.org/show_bug.cgi?id=766341

docs: Fix a typo in GDK sections file

Mention single-stop gradients in the release notes

This is something people stumble over in their custom CSS.

Updated Spanish translation

gdk: Unset the DrawingContext <-> cairo_t link on dispose

When disposing a GdkDrawingContext we should unset the association
between the instance and the Cairo context; this avoids stale pointers
in case a reference that has acquired on the Cairo context survives the
lifetime of the GdkDrawingContext.

gdk: Try harder at tracking drawing contexts

If gdk_cairo_create() is called within a frame draw operation, we can
still associate the Cairo context with a GdkDrawingContext.

Updated Scottish Gaelic translation

Updated Scottish Gaelic translation

Updated Scottish Gaelic translation

Deprecate gtk_widget_send_expose()

We have various replacements for what this function does, and we are not
calling it internally any more.

scrolledwindow: Fix calls to gdk_window_move_resize()

This is a bit of fallout from 34feba1, now that we resolve
the has_indicators value earlier than realize, it becomes
possible to call gdk_window_move_resize() before realization.

Just added the appropriate checks.

docs: point to suggested api for deprecated functions

We deprecated a bunch of _focus_on_click() functions. Point to the new API
in GtkWidget.

docs: Add deprecation notice for GtkButton.set_focus_on_click()

To match the deprecation annotation on the function declaration.

Avoid a deprecation warning

Some debugging code in GdkWindow still calls gdk_cairo_create().

gdk: Deprecate gdk_cairo_create()

We have GdkDrawingContext, now, which is in charge of creating Cairo
contexts for drawing on a GdkWindow.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

gdk: Explicitly create a cairo context inside GdkDrawingContext

Instead of using gdk_cairo_create(), which we'll soon deprecate.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

Deprecate the gdk_window_begin/end_paint family of functions

They are replaced by the more appropriate gdk_window_begin_draw_frame()
and gdk_window_end_draw_frame() functions.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

Associate the drawing context to the Cairo context

Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.

Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

docs: Add GdkDrawingContext to the GDK API reference

https://bugzilla.gnome.org/show_bug.cgi?id=766675

Add GdkDrawingContext

Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.

https://bugzilla.gnome.org/show_bug.cgi?id=766675

scrolledwindow test: Check natural width for max content size

The maximum content size does not increase the minimum request
but only ensures that both minimum and natural requests do not
exceed the maximum setting.

scrolledwindow: Resolve whether we use overlay scrollbars early.

Widgets should support size requests before being realized in general,
otherwise this can cause flicker/resize at initial display time as
the toplevel window can make a request before realize/allocate.

This also makes the added testsuite/gtk/scrolledwindow.c test work again,
this was broken because we only ever calculate whether we are going
to use overlay scrollbars once the scrolled window is realized (and
the test case does not realize any window).

scrolledwindow: Bug 766569 - General size request fixes.

This patch does a couple of things:

  o Removes the obscure 'extra_width' and 'extra_height' variables
    making the request code exceedingly difficult to read

  o Fixes the max-content-size properties introduced in bug 742281
    so that they do not grow the minimum request.

  o Cleanup of request code in general:
    - min/max content sizes are clamped around the child request as needed
    - scrollbar requests are only added in one place, after child request
      sizes are calculated and without the extra_width/height thing.

Fix build

Commit 023f406c9617284ee3b88727df489f20cd066fd6 has a typo that results
in this error:

../../../testsuite/gtk/notify.c: In function 'test_type':
../../../testsuite/gtk/notify.c:679:54: error: expected expression
before ')' token
    (g_str_equal (pspec->name, "max-content-width") ||)
                                                      ^

wayland: Make sure window titles fit into a wl_buffer

A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.

https://bugzilla.gnome.org/show_bug.cgi?id=767241

test: Skip GtkScrolledWindow::max-content- properties

The allowed values for the max-content- properties depend
on the value of the min-content- properties, in a way that
our simple test is not prepared to deal with. Just skip
them for now.

wayland: add extended state for tiled

xdg-shell allows desktop environments to extend the list of states
within a given range.

Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.

https://bugzilla.gnome.org/show_bug.cgi?id=766860

HC: focus outline more prominent

- make visible regardless of colors used
- make larger and more inset

https://bugzilla.gnome.org/show_bug.cgi?id=767310

Adwaita: .osd button.color

remove box-shadow from colorbutton colorswatch when an ancestor has
the osd styleclass applied.

Adwaita: centralize outline-color

define outline-color generally using alpha(currentColor, 0.3),
which avoids setting it in a bunch of different places.

Make gtk_scrolled_window_remove() smart

If gtk_scrolled_window_add() has added a GtkViewport,
  gtk_container_remove (GTK_CONTAINER (scrolled_window), child_widget);
or
  gtk_container_remove(GTK_CONTAINER(scrolled_window),
                       gtk_bin_get_child(GTK_BIN(scrolled_window)));
removes both the added child widget and the viewport.

https://bugzilla.gnome.org/show_bug.cgi?id=710471

Update GtkLabel::angle docs

We can have wrapped or ellipsized labels at an angle nowadays.
Still no selections though.

scale, spinbutton: Avoid -0.0

This is a very longstanding bug; time to finally put it to rest.

https://bugzilla.gnome.org/show_bug.cgi?id=118959

Ensure that GtkRange allocates enough space for the value

This is a long-standing problem of GtkScale.

https://bugzilla.gnome.org/show_bug.cgi?id=766372
https://bugzilla.gnome.org/show_bug.cgi?id=578626
https://bugzilla.gnome.org/show_bug.cgi?id=79229

Fix preconditions in set_max_content_size setters

We must allow resetting the properties to -1.